-
Notifications
You must be signed in to change notification settings - Fork 34
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add super_to_choi and choi_to_super #115
base: master
Are you sure you want to change the base?
Conversation
Codecov ReportAttention: Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## master #115 +/- ##
==========================================
- Coverage 93.00% 90.71% -2.29%
==========================================
Files 25 26 +1
Lines 3104 3254 +150
==========================================
+ Hits 2887 2952 +65
- Misses 217 302 +85 ☔ View full report in Codecov by Sentry. |
@akirakyle , I think here it would be a great place to use the multimethod style of julia. With the current setup you are proposing, the following will be a bit difficult: applying the choi superoperator to some operator. My initial suggestion would be to create
Then you can easily have the same function (e.g. multiplication or Do not hesitate to voice dissent if this seems misguided. Let me know what you think. |
@Krastanov I think it might make sense to keep this in draft status for awhile while I get some experience using the choi representation in my own code to see what feels most natural. I think you might be right in that the safest method would to introduce a |
@Krastanov I am finally getting back to working on this and I noticed that the I will be needing the Kraus representation of superoperators as well so I think I will go ahead and implement a |
I'm also noticing that the constructors for |
7e848f4
to
81a9159
Compare
Hi, Akira! Pardon the slow response, I did not notice that was converted away from draft status. I will try to review this in the next few days. |
Hi, Akira! I guess a week turned into a month, sorry about that. I did some very minor touchup, but feel free to disregard the last commit (by doing a force push here). Otherwise, do not forget to do a pull first to incorporate it. Given other things you have mentioned in this thread, does the following todo list sound reasonable as prerequisite for merging (of course, there is no expectation that you have to do this -- it is already appreciated that you have donated some of your time to start this):
I will add this to the PR description and convert it to a draft for now (that helps me with organizing my own PR-review work). Do not hesitate to convert this back to non-draft and request a review. |
That looks like a solid todo list to me and represents what I would like to see with regards to getting all the common superoperator representations implemented with a reasonable interface. I've been consumed by another research project which is why I haven't been spending time on this lately but I do intended to come back to this at some point, hopefully soon. |
@Krastanov I've finally been coming back to this PR as I've picked up the research project that relies on it again! I've implemented the The conversion from PS: I am currently in Boston until this Sunday, then stonehill until next friday, so if you are around and would like to meet up in person to discuss this or anything else julia/quantum related, let me know when works! |
Unlike qutip, which uses
type = super, superrep = choi
to mark aqobj
as a superoperator in the choi representation, I personally think it makes more sense to just reuse the normalOperator
type to represent a choi matrix since it must be a valid density operator after all. Also it often makes sense to compute things like the Von Neumann entropy of the choi state. To convert back to the superoperator representation, one needs to assume some convention for which of the two Hilbert spaces is the auxiliary/reference/environment system and which represents the channel's output system. I've chosen the convention which seems standard to have the first system be the reference and the second be the output system.I still need to add docs and tests but I thought I'd open this now as a draft so that there can be some discussion of these choices. Also this might be a good time to follow through on the TODO to upstream
_permutedims
and maybe figure out how to make it operate onReshapedSparseArray
?Rough TODO list: